The DNS software administrator will configure each master/slave server supporting a zone to cryptographically authenticate zone transfers.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-4482	DNS0455	SV-4482r2_rule	DCNR-1	High

Description
A slave updates its zone information by requesting a zone transfer from its master. In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master. In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will. To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.

Description

A slave updates its zone information by requesting a zone transfer from its master. In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master. In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will. To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.

STIG	Date
Windows DNS	2015-12-28

Details

Check Text ( C-3531r1_chk )
BIND Instruction: This check is only applicable to slave servers. If there is not an allow-transfer phrase within the zone statement, then this is a CAT I finding. If there is an allow-transfer statement, there must be a TSIG key corresponding to each of the zone partners. The reviewer can validate this by examining the key and server statements within named.conf. Check the keys phrase within each of the server statements. Verify the key statement is configured to cryptographically authenticate the master name server; an example is provided below, if this is not configured, then this is a finding. On the master name server, this is an example of a configured key statement: key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. { algorithm hmac-md5; include "/etc/dns/keys/tsig-example.key"; }; zone “disa.mil” { type master;file “db.disa.mil”; allow-transfer { key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil.; }; }; On the slave name server, this is an example of a configured key statement: key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. { algorithm hmac-,d5; include "/etc/dns/keys/tsig-example.key"; }; server 10.2.2.2 { keys {ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil}; }; zone “disa.mil” { type slave; masters { 10.1.1.1; }; file “db.disa.mil”; }; A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate master servers in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding. Windows 2000/2003 DNS: Instruction: This check only applies if the name server is not active directory integrated. If the Windows DNS zone type is not active directory integrated, then the open the DNS management console snap-in, right click on the zone and select properties. If name servers tab has entries, then this will still be a CAT II finding. If the name servers tab does not have entries, then this is a CAT I. In cases in which the name server is not running BIND or Windows DNS, the reviewer must still examine the configuration and its documentation to validate this requirement. Mitigation: A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate masters in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding.

Check Text ( C-3531r1_chk )

BIND

Instruction: This check is only applicable to slave servers. If there is not an allow-transfer phrase within the zone statement, then this is a CAT I finding. If there is an allow-transfer statement, there must be a TSIG key corresponding to each of the zone partners. The reviewer can validate this by examining the key and server statements within named.conf. Check the keys phrase within each of the server statements. Verify the key statement is configured to cryptographically authenticate the master name server; an example is provided below, if this is not configured, then this is a finding.

On the master name server, this is an example of a configured key statement:

key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. {
algorithm hmac-md5;
include "/etc/dns/keys/tsig-example.key";
};

zone “disa.mil” {
type master;file “db.disa.mil”;
allow-transfer { key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil.; };
};
On the slave name server, this is an example of a configured key statement:

key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. {
algorithm hmac-,d5;
include "/etc/dns/keys/tsig-example.key";
};

server 10.2.2.2 {
keys {ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil};
};

zone “disa.mil” {
type slave;
masters { 10.1.1.1; };
file “db.disa.mil”;
};

A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate master servers in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding.

Windows 2000/2003 DNS:

Instruction: This check only applies if the name server is not active directory integrated. If the Windows DNS zone type is not active directory integrated, then the open the DNS management console snap-in, right click on the zone and select properties. If name servers tab has entries, then this will still be a CAT II finding. If the name servers tab does not have entries, then this is a CAT I.

In cases in which the name server is not running BIND or Windows DNS, the reviewer must still examine the configuration and its documentation to validate this requirement.
Mitigation:
A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate masters in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding.

Fix Text (F-4367r1_fix)
The DNS software administrator should configure each slave supporting a zone to cryptographically authenticate its master before accepting zone updates.